Software applications in the field of enterprise resource planning (“ERP”) attempt to integrate all facets of a business including planning, manufacturing, sales, and marketing. As the ERP methodology has become more popular, software applications have emerged to help business managers implement ERP in business activities such as inventory control, order tracking, customer service, finance and human resources. Because ERP systems attempt to encompass all aspects of a business, they often tend to be extremely complex and multifaceted with large data repositories. Consequently, the user interface experience can sometimes be complex as well.
Frequently, a user attempting to execute a business transaction (e.g., entering a new employee into a human resources database) on an ERP server must perform several tasks or steps that seem unrelated to the ultimate goal of the transaction. For example, many transactions require the user to enter configuration data that does not have an obvious relationship to the end-goal the user is attempting to achieve. Often times this is due to the intricate and complex data dependencies of the underlying data repository and the interrelated components that make up the ERP system.
A second drawback with existing ERP systems is the inability to automate repetitive tasks. For example, a user may have to enter data manually while performing several steps to complete a single transaction. Furthermore, the user might have to repeatedly perform that transaction several times over a given time period. Without the ability to somehow automate the process, the user is faced with the tedious and time-consuming task of manually entering data. The repetitive nature of the manual data entry is not only tiresome for the user, but it also makes the process more prone to mistakes. The problems associated with prior art ERP systems are further described with reference to FIGS. 1 and 2.
In a traditional ERP environment 100, such as that illustrated in FIG. 1, a user accesses a server 105 and initiates a user session via a client application running on a client 120. The client application is generally a thick client, having significant functionality and intelligence built-in. Using the client 120, the user executes transactions on the server 105 to manipulate data 110.
FIG. 2 is a block diagram illustrating a prior art process 210 by which a user might complete a business transaction 202 in a prior art ERP environment. In FIG. 2, the step of initiating a user session is illustrated as step 1 by the square box labeled with the number “1.” Each of the boxes illustrated in FIG. 2 represents a step in a business transaction. The example transaction includes six steps in total, two of the steps having sub-steps associated with different processes. In addition, sub-steps 3.1 and 3.2 occur on a different system, SYSTEM 2. Steps *2 and *4 are flagged with asterisks to denote their special status as steps requiring critical data. Critical data may include data that is unique to the transaction and is directly related to an end-goal 208 of the transaction.
For example, if business transaction 202 represents adding a new employee to a human resources database, critical data may include the employee's name and other personal information as well as the employee's wage or salary information. After initiating the user session and selecting to add a new employee at step 1, step *2 may involve entering the employee's name, address and other personal information into the system. Step 3, and sub-steps 3.1 and 3.2 in particular, involve process 204 on SYSTEM 2. For example, steps 3, 3.1 and 3.2 might require initiating a user session on SYSTEM 2 to add the new employee to a database specific to a particular department before moving on to step *4. Step *4, marked with the asterisk, may involve entering additional critical data, for example, the wage or salary information for the employee. Step 5, which requires interaction with process 2, might require entering the date when the payroll system was last run. While the last date that payroll was run seems to have little bearing on adding a new employee to a human resources database, such data is often required due to the complex data dependencies of traditional ERP systems. As such, step 5 might require running a payroll process. This is indicated in FIG. 2 as process 206. After the payroll date has been entered at step 5, additional configuration data is entered at step 6 before the end-goal 208 is reached.
As such, the example business transaction illustrated in FIG. 2 contains six steps; however, only steps 2 and 4 require critical data directly associated with the end-goal 208 of the transaction. The other steps involve entering non-critical and configuration data. Consequently, the end-user is faced with monotonous and tedious data entry tasks that are not obviously related to the end-goal 208.